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ABSTRACT 

Cohesion is a core design quality that has a great impact 
on posterior development and maintenance. By the na- 
ture of software, the cohesion of a system is diminished as 
the system evolves. God classes are code defects resulting 
from software evolution, having heterogeneous responsibili- 
ties highly coupled with other classes and often large in size, 
which makes it difficult to maintain the system. The exist- 
ing work on identifying and decomposing God classes heavily 
relies on internal class information to identify God classes 
and responsibilities. However, in object-oriented systems, 
responsibilities should be analyzed with respect to not only 
internal class information, but also method interactions. In 
this paper, we present a novel approach for detecting God 
classes and decomposing their responsibilities based on the 
semantics of methods and method interactions. We eval- 
uate the approach using JMeter v2.5.1 and the results are 
promising. 
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1. INTRODUCTION 

Object-oriented development (OOD) is responsibility-driven. 
A class is assigned a single responsibility to carry out its 
intended purpose, having high cohesion. However, by the 
nature of software evolution, a single responsibility is of- 
ten diminished with other responsibilities mixed by changes, 
which decreases the cohesion of the class and further that of 
the system as a whole. Such a class is desired to be restruc- 
tured. 

Software evolution is often ad-hoc, which makes it difficult 
to identify classes needing refactoring. Class size is often 



used as an initial screening However, even though class 
size is small, the class might still need refactoring if it in- 
volves multiple responsibilities. High fan-in and fan-out is 
another symptom of God classes [2] . However, that is not al- 
ways the case, for example facade or proxy classes whose the 
main responsibility is delegation. Another symptom is high 
complexity of methods [3]. A sorting class often involves 
complex methods, but is generally not large. As such, iden- 
tifying refactoring needs can be subjective depending on the 
type of the system and developer's experience and requires 
techniques that enable systematic detection in consideration 
of various aspects. 

God classes (also known as Large classes or Blobs) are code 
defects resulting from software evolution, having diverse re- 
sponsibilities highly coupled with other classes and often 
large in size, which makes it difficult to maintain the sys- 
tem. Thus, the more God classes exist, the lower cohesion 
is. God classes might be inherent from design during devel- 
opment, which is a design defect [4]. 

There is some work on decomposing God classes (also known 
as class extraction or refactoring). The general approach of 
the existing work is using internal class information such 
as attribute-method relationships and internal method calls 
to identify class responsibilities O [H (6] [T] |8]. However, 
in object-oriented systems, identifying responsibilities solely 
based on internal class information is very limited without 
considering interaction behaviors. More recent work makes 
use of semantic similarity of methods captured in in-line 
comments and identifier names, assuming that the necessary 
information is sufficiently available 1101 111) . 

A key in decomposing responsibilities is to derive precise 
semantics of methods, so that homogeneous methods can 
be identified and grouped together into a separate class. In 
this paper, we present a semantic-based approach for detect- 
ing God classes and identifying their responsibilities based 
on semantic similarity of methods. Semantic similarity of 
methods is measured based on 1) inter-class interactions of 
methods, 2) intra-class interactions of methods, and 3) types 
of class relationships. We adopt the taxonomy by Resnik [12] 
for analyzing inter-class interactions of methods. The results 
of the taxonomy are refined by considering intra-class inter- 
actions of methods and further refined using types of class 



relationships. The refined results are used for detecting God 
classes using weighted graphs and decomposing their respon- 
sibilities. We evaluate the presented approach using JMeter 
v2.5.1, a widely used open source application for load test- 
ing and measuring server performance and the results are 
promising. We design the approach to support its use at 
both design level and code level. 

The remainder of the paper is organized as follows. Sec- 
tion [5] discusses an overview of related work. Section [3] gives 
an overview of the presented approach. Section |4] describes 
a structural taxonomy for measuring and refining seman- 
tic similarity of methods. Section [5] presents detecting God 
classes and identifying and decomposing their responsibili- 
ties. Section [5] evaluates the presented approach using JMe- 
ter v.2.5.1 and the paper is concluded in Section [T] 

2. RELATED WORK 

There is much work on cohesion metrics. Ghidamber and 
Kemerer presented Lack of Cohesion Metric (LCOMl) for 
measuring the number of the method pairs that reference no 
common attributes 13]. The higher the number of meth- 
ods pairs, the lower cohesion. Revising LCOMl, they pre- 
sented LCOM2 to measure class cohesion by subtracting 
the number of the method pairs that share attributes from 
LCOMl '3^. Li and Henry [H] redefine the concept of LOOM 
by defining sets of methods that share an attribute. A 
method that shares an attribute with any method in a set 
becomes a member of the set. To this end, the resulting 
sets are completely disjoint and the number of the result- 
ing sets indicates the cohesiveness of the class. That is, 
the higher the number of sets, the lower cohesiveness. Hitz 
and Montazeri represent LOOM by Li and Henry using 
undirected graphs where a node represents a method and 
an edge represents attribute sharing by the paired meth- 
ods. Cohesiveness is then measured by the number of re- 
sulting graphs, which is known as LCOM3. They also pro- 
pose LCOM4 to take into account indirect reference to at- 
tributes. An edge is established between a method having a 
direct reference to an attribute and a method invoking the 
directly referencing method. Hendersen-Sellers [TBJ proposes 
LCOM5 which measures cohesion based on the number of 
referenced attributes. The higher cohesion, the larger the 
number of referenced variables. Bieman and Kang [17] pro- 
posed Tight Class Cohesion (TCC) and Loose Class Cohe- 
sion (LCC) based on direct and indirect connectivity among 
methods. Marcus et al 18. present Conceptual Cohesion 
of Classes (C3) to measure method similarity based on tex- 
tual coherence of in-line comments and identifier names in 
source code. Briand et al. present Ratio of Cohesive In- 
teraction (RCI) which measures cohesiveness of a class as a 
ratio of the number of current interactions between method- 
to-data and data-to-data over the total number of possible 
interactions. 

Several researchers use a property-based approach for de- 
composing God classes (e.g., see O [H [G] [?])■ The general 
approach is that the methods of a God class are measured 
for their similarity based on method-attribute relationships 
(e.g., methods sharing an attribute) and method-method re- 
lationships (e.g., method calls) using metrics (e.g., jaccard 
similarity metric [22 )• The resulting similarity is then used 
as a basis for decomposing the God class. Specifically, Si- 



mon et al. [5] measure similarity of methods based on the 
distance of attribute use and method call. Distance is short 
if one is dedicated to another (e.g., an attribute is used only 
in one method). Extending the work by Simon et al., Fokaefs 
and Tsantalis ,8; use a clustering algorithm for decomposing 
properties of a God class. Cassell et al. [7j use call graphs 
for presenting the relationship of methods and attributes 
and employee the Girvan-Newman betweeness clustering al- 
gorithm [21] for decomposing a Large class. Extending the 
property-based approach, Bavota et al. [TT] make use of 
identifier names and in-line comments to measure similar- 
ity of methods using the LSI algorithm [25], a technique 
for measuring similarity of documents in the area of infor- 
mation retrieval. The resulting similarity is represented in 
a weighted graph where a node represents a method and 
an edge represents a pairwise relation of methods. The 
MaxFlow-MinCut algorithm [23] is used to decompose the 
similarity graph. Their work assumes that there exist am- 
ple in-line comments and a naming convention for identifiers 
instilling the intended context into the name, which is not 
always the case. 

There exists some work on detecting God classes. Chatzige- 
orgiou et al. 1 present a design-based approach for identi- 
fying God classes. They use collaboration diagrams to iden- 
tify objects having significant interactions by observing the 
number of links between objects. Objects that have high 
fan-in and fan-out are candidates of God classes. However, 
that is not always the case, for example facade and proxy 
classes often have high fan-in and fan-out, but have a single 
responsibility of delegation. Joshi and Joshi 6^ present a 
lattice-based approach for identifying less cohesive classes. 
A lattice captures attribute references in methods. They 
propose seven types of lattices of which five types are cohe- 
sive and the other two are less cohesive. A lattice conforming 
to the less cohesive types is advised to be decomposed. Mari- 
nescu [4] proposes metric-based rules for identifying God 
classes. They observe common symptoms of God classes 
such as high complexity, low cohesiveness, and frequent ac- 
cess to data in other classes. These symptoms are detected 
using Weighted Method Count (WMC) [3], Tight Class Co- 
hesion (TCC) [17], and Access To Foreign Data (ATFD) [24] . 
Daniel et al. [1] extend the work by Marinescu using histor- 
ical data. Classes are classified by frequency of change and 
the degree of change in size observed in history. The higher 
frequency and degree of change, the more likelihood of being 
God classes. 

In summary, the existing work on detecting God classes 
and decomposing responsibilities heavily relies on intra-class 
information (e.g., attribute-method relationships, internal 
method dependencies, in-line comments). However, object- 
oriented systems are collaborative by nature and it is hard 
to derive precise semantics of methods without considering 
class interactions. In this work, we use both intra-class in- 
formation and inter-class information with more emphasis 
on the latter. Unlike the existing work, the presented ap- 
proach can be used at both the design level and the code 
level. At the design level, the approach can be used for class 
diagrams and sequence diagrams, which enables to detect 
God classes early in development phase. 

3. OVERVIEW OF APPROACH 



In this work, we view a class having a purpose for its ex- 
istence. In the view, we define a responsibility as a set of 
methods to achieve the intended purpose of the class. Given 
that, the approach aims at detecting God classes and decom- 
posing their responsibilities to be a single responsibility per 
class. Figure [1] shows an overview of the approach. In the 
approach, God classes are detected based on pairwise se- 
mantic analysis of methods using Resnik's taxonomy [12| . 
In the taxonomy, relative similarity for every pair of meth- 
ods is measured based on the architectural structure of the 
system using the Semantic Similarity (SS) metric. The re- 
sulting similarity captures the structural distance between 
the paired methods which we use as a base for measuring 
the semantic similarity of the methods. The closer in dis- 
tance, the more similar in semantics. The resulting similar- 
ity is then refined by considering class relationships which 
are not taken into account in the structural taxonomy. The 
refined similarity is then further refined by considering in- 
ternal method call dependencies within the same class. 




Figure 1: Process Overview 

A God class is detected using a set of metrics including 
Interaction-based Cohesiveness (IC), Coupling Between Ob- 
ject (CBO) [3], and Number Of Methods (NOM) [25]. IC 
measures the cohesiveness of a class based on similarity of 
the methods that interact with the class. Method interac- 
tions are measured using Interaction-based Semantic Simi- 
larity (ISS) based on the structural taxonomy. CBO mea- 
sures the coupling of a class based on the interactions of the 
class with other classes, while NOM measures the number 
of methods defined in a class. Detected God classes are ana- 
lyzed for their responsibilities using a threshold determined 
by the average and standard deviation of ISS. The resulting 
analysis advises a solution for decomposition of responsibil- 
ities. We use complete weighted graphs to represent the 
solution. 

4. SEMANTIC SIMILARITY 

In this section, we describe analyzing semantic similarity 
of methods by adopting Resnik's taxonomy [1^. Figure [2] 
shows an example of the taxonomy capturing the structure 
of a system in a tree where leafs represent methods and non- 
leafs represent either classes or (sub) packages. For example, 
in the figure, methods Ml, M2, and M3 are defined in class 



CI and classes CI and C2 belong to package P2 which is 
a sub-package of PI. Each node in the tree has its relative 
distance to other entities. The distance is measured using 
the following metrics |26) : 



SS{ei,ej) = -logP{ls{ei,ej)) 



where ls{ei, Cj) is the lowest superordinate of d and Cj 



P(e) = 



\se{e)\ 
N 



where se(e) is the set of sub-entities of e and A'' is the total 
number of nodes. 
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Figure 2: A Semantic Taxonomy of Entities 

In Figure [2j the relative distance of Mi and M4 is measured 
0.54 by SS{Mi,M4) = -logP{ls{Mi, M4)) where Zs(Mi, M4) 
is Pa. P(P2) is where se(P2) = {Ci, C2, Mi, M2, 

Ah, Ma}. Thus, P(P2) = ^ = 0.29 and SS{Mi,Ma) = 
—logO.29 — 0.54. We use the distance as the semantic simi- 
larity of Ml and M4. Similarly, the distance of Mi and M5 
is measured 0.02. The distances are interpreted that Mi is 
more similar to AI4 in semantics than to M5 since Mi and 
M4 belong to the same sub-package. In the tree, leafs have 
the maximum similarity since their similarity is measured to 
themselves. Table [T] shows the results of the taxonomy in 
matrix. One may consider class libraries in the taxonomy 
for better results if the results outweigh the overhead. 



Table 1: Similarity Matrix 

M, M, Mj M, M,, Mj t 



1.32 0.85 
1.32 



0.54 
0.54 



0.02 0.02 
0.02 0.02 



0.02 0.02 
1.32 0.54 



0.02 0.02 
0.02 0.02 



0.02 0.02 
0.02 0.02 



1.32 0.72 
1.32 



4.1 Refining Using Class Relationships 

The similarities in Table [T] consider only the structural rela- 
tionships of entities. We refine the similarities by considering 
types of class relationships which are not captured in the 
taxonomy. We consider 1) inner relationships, 2) general- 
izations, 3) aggregations, 4) associations and dependencies, 
which are in the order of high to low in weight. Inner rela- 
tionships are weighted 1.5, which is the highest, as the inner 
class and the outer class have the full access each other. Gen- 
eralizations are weighted the second 1.4, since child classes 
can inherit the properties of the parent class, but not all. Ag- 
gregations are stronger than associations and dependencies 
due to the whole-and-part constraint and weighted 1.3. As- 
sociations and dependencies are weighted same 1.2 as they 
can be interchangeably used, although dependencies are a 
little more limited in use. The range is weights is deter- 
mined in consideration of the relative influence of class rela- 
tionships to method similarity. Considering these types with 
different weights refines the similarities from the structural 
taxonomy. 



I 



Figure 3: Class Relationships 

Table [5] shows the refined similarities for the relationships 
given in Figure [S] For instance, the similarity of methods 
Ml and M3 in Table [T] is 0.54 and it is refined to 0.76 (0.54 
X 1.4) by considering the generalization in Figure [S] Re- 
fined similarities are shown in bold in the table. Note that 
the refined similarity might be greater than the maximum 
similarity (1.32) in Table [T] which is conceptually not valid 
(as nothing can be more similar than itself). To remedy 
this, the minimum value that makes the maximum similar- 
ity greater than the refined value in multiplication is used. 
This value is referred to as tapping constant. 



Table 2: Refined Similarities with Weighed Class 
Relationships 
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4.2 Refining Using Method Call Dependencies 

We further refine the similarities resulting from Subsection l4.1l 
by considering method call dependencies within the same 
class. Having a call dependency between methods belonging 
to the same class shows a great intimacy and their similarity 



is doubled. Method call dependencies are weighed higher 
than class relationships as method dependencies are more 
influential to the semantic similarity of methods than class 
relationships. Suppose method Mi has a call dependency 
on method M2 . Given this, the similarities in Table [5] are 
refined as shown in Table [3] where the similarity of Mi and 
M2 is refined to 1.7 from 0.85. A tapping constant can be 
used if the refined value becomes greater than the maximum 
similarity. 



Table 3: Refined Similarities with Weighed Call De- 
pendency within the Same Class 



1.7 0.85 
2.64 0.85 



0.86 
0.86 



0.86 
2.64 
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2.64 



0.02 0.02 
0.02 0.02 



0.02 0.02 
0.02 0.02 



0.02 0.02 
0.02 0.02 



5. EXTRACTING RESPONSIBILITIES OF 
GOD CLASS 

The similarities resulting from Section [4] capture only the 
similarity of methods across classes and do not fully capture 
the similarities of the methods in the same class. This is 
because the base taxonomy used in Section 0] is built upon 
the structure of entities which does not carry any internal 
information of a class. For this reason, the same similar- 
ity is shown in Figure [5] for the methods in the same class 
(e.g., methods Mi, M2, and M3 in class Ci have the same 
similarity 0.85). The refinement in Subsection 14.21 measures 
limited similarity of internal methods by considering internal 
method dependencies. For the full extent of measuring the 
similarity of the same class methods, we make use of method 
interactions. That is, the similarity of the same class meth- 
ods are measured "indirectly" through the similarity of their 
interacting methods in other classes, which is referred to as 
Interaction-based Semantic Similarity (ISS). ISS of methods 
mi and m, is measured as follows: 



ISS{mi,mj) =mss{Fi„{mi), Fi„{mj)) 

+ mss{Fout{mi),Fout{mj)) 
+ SS{mi, rrij) 



E 



mssimsi.msi =- 



SS{mi,mj) 



\msi\ X \msi 



where Fin{m) is the fan-in function of method m returning 
the set of invoking methods for m and Foutirn) is the fan-out 
function returning the set of invoked methods and SS(mi, 
rrij) is the similarity of methods rm and mj found in TableO 
For example, suppose that we measure the similarity of Mi 
and M2 in Figure ID In the figure, the fan-in of Mi and 
M2 is {Mi}, the fan-out of Mi is {Me, M7}, and the fan- 



out of M2 is {Mr}. Based on Table [S] mss{{M4,}, {M4}) 
= 2.64, mss{{M6, M7}, {M7}) = 1.33 and SS{Mi,M2) = 
1.7, which results in ISS(Mi, M2) = 5.67. The similarity 
of other pairs can be computed (ISS(Mi, M3) = 1.24 and 
ISS(M2, M3) = 1.59). 
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Figure 4: Fan-In and Fan-Out of Methods 



5.1 Detecting God Classes 

God classes are often large in size and have high coupling 
with other classes and low cohesion with respect to the sim- 
ilarity of interacting methods [271 128] . Given this observa- 
tion, we identify God classes using a set of metrics includ- 
ing Interaction-based Cohesiveness (IC), Number of Meth- 
ods (NOM) and Coupling Between Objects (CBO) |3]. 
IC measures the cohesiveness of a class based on the simi- 
larity of the methods that interact with the class as follows: 



where M is the set of the methods in class c and 7^ rrij. 
For instance, IC of the class Ci in Figure|4]is measured 2.18. 
CBO measures the coupling of a class based on the interac- 
tions of the class with other classes, while NOM measures 
the number of methods defined in a class. Using IC, CBO, 
and NOM, we define the following rule for detecting God 
classes: 



GC{S) ={c G C\{NOPI{c) > 3rdQuartile{S)) 
A{CBO{c) > SrdQuartile{S)) 
A(/C(c) < 3rdQuartile{S))} 

where C is the set of classes defined in system 5*. In the 
rule, IC, NOM, and CBO are set to the 3rd quartile as a 
default. We use box plots to represent statistical filtering. A 
detected god class is represented using a complete weighted 
graph where a node represents a method and the weight on 
each edge represents the semantic similarity of the paired 
methods linked by the edge. Figure [5] shows an example 
graph for the class Ci in Figure (2] 

5.2 Decomposing Responsibilities 

God class graphs resulting from Subsection lS.ll are analyzed 
for decomposition of responsibilities using a threshold. A 
threshold e is determined as follows: 




Figure 5: Example of complete weighted graph 



e = [fj, — a, n + a] 

if fi — a < MinW eight then e — MinW eight 
if jj, + a > MaxWeight then e = MaxW eight 

where p is the average of weights and cr is the standard devi- 
ation of weights. The threshold guarantees the edge of two 
nodes having the weight (similarity) lower than the thresh- 
old to be removed, which splits the God class graph into 
sub-graphs, each capturing a single responsibility. Figure [6] 
shows two sub-graphs split from the God class graph Figure 
[5] by a threshold ranging from 0.37 to 5.30. 




Figure 6: Splitting Responsibilities 

6. CASE STUDY: JMETER 

We use JMeter v. 2. 5.1 t29j, a Java-based open source for 
load testing and measuring performance of a server, to eval- 
uate the presented approach. The version used in this study 
involves 405 packages, 1,623 classes, 9,005 methods, and 30 
libraries with 2.5 years of maintenance. The size of the ap- 
plication is 145 KLOC and the average NOM and the av- 
erage CBO are 8.5 and 11.1, respectively. In applying the 
approach, the structural taxonomy involves 11,033 entities 
in total including classes, methods, and packages, which re- 
sults in a 9,005 x 9,005 similarity matrix. Figure [7| shows 
partial results of the taxonomy and a corresponding matrix 
is shown in Tabled In this study, we also consider libraries 
in similarity analysis. The dashed box in Figure [7] shows a 
subset of the considered libraries. The great deviation be- 
tween the minimum value and the maximum value in Table|4] 
is a hint of the large number of entities used in this study. 

The similarities in Table [4] are refined in consideration of 
class relationships. There are 176 inner class relationships, 
187 generalizations, 655 associations/dependencies found. 
Applying the weights for class relationships in Section U 
the similarities are refined to Table [5] 

The similarities in Table [5] are further refined in considera- 
tion of method call dependencies which involve 4,066 depen- 
dencies. Table |6] shows the refined similarities. 
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Figure 7: Structural Taxonomy of JMeter v2.5.1 
Table 4: Semantic Similarities of JMeter v2.5.1 
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Table 5: Refined Similarities of JMeter v2.5.1 with 
Class Relationships 
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Table 6: Refined Similarities of JMeter v2.5.1 with 
Method Call Dependencies 
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5.4 


5.4 


2.7 


1.6 
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0.0001 


found 
Class 
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0.00012 
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make 
Menu 
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Based on the resulting similarities in Table [6l the 3rd quar- 
tile of CBO, NOM, and IC is measured 9.0, 6.0 and 1.22, 
respectively, which leads to the following detecting rule: 



detected as candidate God classes. Table [7| shows the list of 
the detected classes. 



GC{JMeterv2.5.1) ={c G C\{NOM{c) > 9.0) 
A{CBO{c) > 6.0) 
A(JC(c) < 1.22)} 

where C is the set of the classes in JMeter v2.5.1. Figure [8] 
shows box plots for CBO, NOM, and IC. 

By applying the rule, six classes out of 1,623 classes are 



Table 7: Candidate God Classes 



God Class 


NOM 


CBO 


ICM 


MenuFactory 


22 


46 


1.12 


ProxyControl 


29 


57 


0.98 


SampleResult 


23 


252 


0.98 


AbstractTestElement 


24 


30 


1.20 


ProxyControlGUI 


22 


58 


1.08 




Table 8: Thresholds and ISS Statistics 



Figure 8: Measures of CBO, NOM, and IC 



For each candidate class, a complete weighted graph is built. 
Figure [9ja) shows the graph for the MenuFactory class. 
The graph involves 22 nodes representing the methods de- 
fined in the class and 231 edges connecting the nodes. The 
threshold for the class ranges from 0.95 to 2.09 and we ex- 
perimented a threshold ranging from 1 to 2.1 incremented by 
0.1. No edge is removed with threshold 1.0 causing no split 
and 217 edges are removed with threshold 2.1 resulting in 
three sub-graphs. In a manually verification, threshold 1.5 
produces the best result, which decomposes into two sub- 
graphs with 157 edges removed, each sub-graph representing 
a single responsibility. One sub-graph involves 18 methods 
and the other involves 4 methods. Figure |5]^b) shows the re- 
sulting decomposition. Table [8] shows the threshold ranges 
used in experiments for each of the candidate God classes. 



6.1 Results Analysis 

From the case study, we observe three types of God classes 
shown in Figure [10] Type A has two heterogeneous respon- 
sibilities, each having an independent set of fan-in and fan- 
out interactions, which should be put in a separate class. 
This is an example of a obvious need for responsibility de- 
composition. The MenuFactory, SampleResult , and Ab- 
stractTestElement classes belong to Type A. The ManuFac- 
tory class has responsibilities of 1) creating menus and 2) 
controlling the drag and drop function. While the drag and 
drop function supports menus, its controlling responsibility 
is not directly related to menus. The SampleResult class 
involves responsibilities of 1) collecting and storing sample 
results and 2) measuring the time taken to collect sample 
results. The collecting and storing functions in the first re- 
sponsibility is quite heterogeneous to the measuring function 
in the second responsibility. The AbstractTestElementclass 
has responsibilities of 1) configuring properties of tested ele- 
ments and 2)configuring thread context. The target objects 
concerned in the two responsibilities are completely different 
types, and thus the responsibilities share no commonality. 



God Class 


Interval of e 


Item 


Value 


MenuFactory 


0.95-2.09 


Mean 


1.12 


Std. Dev. 


0.97 


Min 


0.95 


Max 


7.70 


ProxyControl 


0.86-2.32 


Mean 


0.98 


Std. Dev. 


1.34 


Min 


0.86 


Max 


6.87 


SampleResult 


0.78-1.50 


Mean 


0.98 


Std. Dev. 


0.53 


Min 


0.78 


Max 


5.60 


Element 


0.90- 1. 81 


JVlean 


1.20 


Std. Dev 


0.61 


Min 


0.90 


Max 


4.80 


ProxyControlGUI 


0.98-1.48 


Mean 


1.08 


Std. Dev. 


0.40 


Min 


0.98 


Max 


4.80 



Figure 10: Three Types of Detected God Classes 



Type B also involves two responsibilities. However, unlike 
Type A, the responsibilities in Type B have a dependency. 
When the responsibilities are split into two classes, the de- 
pendency is realized as an association between the classes. 
The ProxyControlGUI class is in Type B. As the name 
implies, the class involves two dependent responsibilities in- 
cluding 1) creating and controlling GUI and 2) controlling 
proxies. The proxy responsibility should be separated and 
put into the ProxyControl class which is associated with 
the ProxyControlCU I class. Type B is an example of the 
Feature Envy smell 28 which violates the principle of group- 
ing behaviors by related data and occurs when a method is 
more interested in being in another class than the current 
class. 

Type C have also two responsibilities that have an indi- 
rect dependency via a class. At the class level, the depen- 
dency appears as a bidirectional dependency (or associa- 
tion). From an implementation view, a bidirectional depen- 
dency is costly as two-way links should be manipulated for 
creating, accessing, and removing objects, which would not 
have to be dealt if the responsibilities are separated. The 
ProxyControl class belongs to Type C. The ProxyControl 
class involves responsibilities of 1) starting and stopping 



(b) 



Figure 9: Decomposing Responsibilities of the MenuFactory Class 



proxies and notifying start and stop of proxies to other ob- 
jects and 2) receiving tlie resulting data from proxies and 
delegating the data to other objects. The first responsibility 
depends on the Proxy class, which in turn depends on the 
second responsibility. Such a bidirectional association is not 
a common practice and is often a source of errors [28j . 

6.2 Verifying Results 

We verify the accuracy of the decomposition results by com- 
paring them with manual results produced by two software 
engineers having 5-year and 2- year industry experience. The 
engineers manually reviewed the detected classes and their 
interacting classes for identifying responsibilities. The re- 
sults of the manual review are shown in Table |9l 

Let i?(c) = {ri, r2, r-„} be the set of manually identi- 
fied responsibilities of class c where = {mi, m2, nip} 
is a set of methods. Let -R'(c) = {ri, r2, r^„} be the 
set of the responsibilities identified by the presented ap- 
proach where r[ = {m'l, 7712, m^} is a set of methods. 
For ri £ R and r'j G R' , the best matching responsibility in 

R IS ri,„„, = arqmax -, — 7—, , 



Given that, the accuracy of 



r'- U r. 
J * 

the presented approach can be measured using the following 
precision, recall, and F-Measure: 



• Precision: The number of correctly identified methods 
of a responsibility to its best matching responsibility 
r'h^^t over the number of the identified methods of r-i. 



Precision : P(r'i) 



I n r[,g 



Recall: The number of correctly identified methods of 
a responsibility to its best matching responsibility 
''''best over the number of the defining methods of r^. 



Recall : R{ri) = 



I ri n r^.^t I 



F-Measure: A composite measure of P(ri) and R{ri) 
for responsibility ri. 



F — Measure : F{ri) = 



2 ■ P{r^) ■ Rjrr) 



P(r,) + R{ri) 



F(GC) = 



\R\ 



\R\ 



\R\ 



\R\ 



Figure [TT] shows the results of F-Measure for the detected 
God classes per change of threshold. The results in the 
graph are capricious, which indicates a high deviation of 
ISS. In fact, the likelihood of being split for a God class 
graph increases as the deviation of edge weights increases. 
Therefore, the results indicate a high likelihood of decom- 
position for the detected classes. The graph also show high 
accuracy of the results in the threshold range of 1.3 and 1.5. 
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Figure 11: F-Measure for Detected God Classes 

In Table [O] the average of the best F- Measures for the de- 
tected God classes is 0.919 which is promising. In particular, 
the responsibilities of the MenuFactory and ProxyControl 
class are identified exactly the same as the manually found 
ones. In this study, the accuracy of the detecting rule is not 




Table 9: The best accuracy measure 



God Class 


Responsibility 


SMethod 


Precision 


Recall 


F-Measure 


Engineers 
extracted 


Automatically 
extracted 


Found 


Matched 


MenuFacrory 
(1.3) 


(1) Creating/Controlling Menu 


18 


18 


18 


1 


1 


1 


(2) Controlling Drag/Drop Functionality 


4 


4 


4 








ProxyContro! 
(1.3) 


(1) Controlling Proxies 


11 


11 


11 


1 


1 


1 


(2) Receiving/Delivering Result from 


18 


18 


18 


, 


, 


, 


SampleResult 
(1.0) 


(1) Creating and Having Result 


16 


16 


16 


1 


1 


1 


(2) Measuring Time 


9 


10 


8 


0.8 


0.889 


0.842 


AbstractTest 
Element (1.1) 


(1) Configuring Properties of Test 
Elements 


26 


25 


25 


1 


0.961 


0.98 


(2) Configuring Thread Context 


2 


1 


1 




0.5 


0.667 


Proxy Control 
GUI(l.l) 


(1) Creating/Controlling GUI 


11 


11 


11 




1 


1 


(2) Controlling Proxies 


14 


9 


8 


0.889 


0.571 


0.696 




average 


0.969 


0.892 


0.919 


std. dev. 


0.069 


0.192 


0.134 



measured as it is not feasible to identify the actually exist- 
ing God classes in JMeter due to subjectivity and the large 
number of classes (1,623). 

7. CONCLUSION 

In this paper, we have presented a semantic-based approach 
for detecting God classes and decomposing their responsibil- 
ities. The approach measures semantic similarity of methods 
using inter and intra-interactions of methods and class rela- 
tionships. The resulting similarity is used as a basis for iden- 
tifying God classes using the NOM, CBO, and IC metrics. 
Detected God classes are represented in a weighted graph 
for responsibility analysis and decomposition. Responsibil- 
ities are identified based on relative semantic similarity of 
defined methods in the God class to the similarity of their 
interacting methods in other classes. Responsibilities are 
decomposed by a threshold determined by the average and 
standard deviation of ISS. We evaluate the approach using 
JMeter v2.5.1. 

The presented approach does not require code details (e.g., 
attribute- method references), and therefore can be used at 
both design level and code level. In this paper, we did not 
consider constructors, getters, and setters since they are not 
captured at design level. At code level, however, construc- 
tors may be a subject of interest in detecting God classes 
and decomposing responsibilities. Getters and setters at 
code level can help to improve the precision of similarity 
if they are referenced in other methods, which basically cap- 
tures attribute-method references. Similarity precision can 
be further improved if libraries are considered in the taxon- 
omy. However, it involves an overhead and is recommended 
only when the accuracy of the expected results outweigh the 
overhead. 
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